Mobile devices such as cell phones and personal digital assistants (PDAs) can be attacked by exploits or viruses that are specifically adapted for the mobile environment. Exploits can take advantage of security vulnerabilities associated with a mobile device in order to execute malicious code or perform undesired actions on the device. Potentially, exploits can bypass permissions or policies set by the user, manufacturer, operating system, or mobile operator and give the attacker complete control of the device. Mobile viruses are typically spread by downloading infected programs or files. Some viruses only become active if the recipient chooses to accept the virus file and run it on the mobile device. Other viruses, when combined with exploits, are self-propagating worms that may not need user intervention in order to spread, potentially creating a very severe and widespread security problem.
Devices may be compromised by viruses and exploits over wide area networks, such as the Internet or a cellular network, and local wireless networks, such as Wi-Fi or Bluetooth. For example, some devices which are equipped with Bluetooth allow other nearby Bluetooth-enabled devices to transfer files or other data such as contact information. Bluetooth-enabled devices that are infected with viruses often search for nearby devices that are in “discoverable” mode. When an infected device discovers a target, it may send a virus disguised as a security update or another item designed to fool the target device's user into accepting the transfer and executing the virus. If a virus were to utilize an exploit instead of disguising itself in order to get a target user to accept the file transfer, a device which is in “discoverable” mode could become infected without the user being able to intervene.
In addition to being able to propagate viruses, exploits may be able to directly perform malicious actions on vulnerable devices. Such exploits may be used by attackers to steal information, charge money to the target device's phone bill, or prevent a device from functioning properly. Although vulnerabilities which take advantage of exploits may be fixed if the software vendor responsible for the vulnerability provides a patch or firmware upgrade, such fixes are often costly and time consuming to release and difficult for users or IT organizations to apply.
It is important that both individual users and IT organization be able to verify that their security protection is functioning properly and be aware of the security state of their devices so as to be able to remediate or investigate issues as early as possible. If a device or group of devices has a security problem or has recently been attacked, the user or administrator responsible may not immediately know because mobile devices and existing solutions may not continuously present security status information and attempt to push important events to users and administrators.
What is needed is a system and method for identifying, reporting, and preventing mobile security problems and for providing security information concerning the state of a mobile device or group of mobile devices to a user or administrator. The system and method should keep users or administrators continuously aware of security status, recent security-related events, and potential security threats without requiring them to repeatedly seek out security-related information.
Because of inherent security concerns, mobile communications devices such as mobile phones, PDAs, and smartphones have yet to provide the same breadth of trusted connectivity found on desktop and laptop computer platforms. For example, mobile device users are less likely to access confidential information and/or perform financial transactions with a mobile communications device because such devices are not sufficiently secure. Similarly, service providers such as banks, online payment services and providers of confidential information are less likely to offer access to their services through mobile communications devices. As a result, mobile communications device users are limited by the types and availability of many online services. This is because present methods for securing mobile communications devices do not contemplate many ways users may wish to access online services and online service providers, and are therefore inadequate for providing a secure platform for access to and from online services or service providers.
Previous methods for securing mobile communications devices focus on an all-or-nothing approach. Access to or from the mobile device is either granted or not granted based upon whether the device meets certain standards, possesses certain configurations, or adheres to certain policy rules. If the device passes these standards, access is granted. If the device is deficient in any way, access is denied. Such an approach does not consider the types or levels of access required by certain service providers, nor does this approach contemplate the security and repair capabilities of the device itself. Indeed, prior art security systems and methods ignore the recent activity of the mobile device in relation to its overall security state. Furthermore, prior art security systems are typically limited to authorizing access to a given network, making them unsuitable for controlling access and access levels to services and service providers based on a device's security state.
What is therefore needed is a system and method for providing security for mobile communications devices that considers the security state of the device and provides a platform for integrating with services and service providers.
The mobile market has grown significantly in the last few years. As new mobile communications devices come to market, each offers new sets of hardware features that are attractive and useful to consumers. Unfortunately, software development for mobile communications devices has not kept pace with hardware development. This is because each mobile communications device will often use a different operating system, software platform, or set of application program interfaces (“APIs”), even if each mobile communications device is made from the same manufacturer. Additionally, each mobile communications service provider or carrier will often customize the performance, configuration, and interface for each device that it services. As a result, there is wide divergence between the software platforms and software development for mobile communications devices.
In order to unify the different software platforms available for mobile communications devices in a market where there are numerous manufacturers and providers, there has been some effort to develop cross-platform solutions. Cross-platform refers to operating systems or software applications that are designed to work on multiple platforms without requiring significant changes to the underlying software code. In general, cross-platform architecture is more common and more easily implemented on desktop computing platforms due to the availability of memory and processing resources and the standardization of interfaces on each type of platform. Desktop cross-platform systems do not transfer well to mobile devices that lack these resources. Instead, cross-platform developers will sacrifice or adopt different methodologies in order to provide a system that is powerful enough to handle different applications across as many platforms as possible, while maintaining a low memory footprint.
The typical cross-platform system will comprise a component or module that is platform-independent, a component or module that is platform-specific, and an abstraction layer that may be utilized by either of the other components. These components or modules are generally software-based, but are designed to incorporate the commonalities and unique differences of the hardware upon which they are installed. Each component will communicate with others using its own API. This presents a problem in not having a uniform API for developers to use. In order to provide compatibility on as many devices as possible, developers will abstract the underlying platform such that the various differences are not apparent. For example, the abstraction layer's API is often designed to be general and non-specific to the platform upon which it operates or the functionality it is being used to implement. Additionally or alternatively, the cross-platform system may incorporate a powerful all-inclusive abstraction layer that provides some functionality that is duplicated between platforms, thereby implementing a general, multi-purpose layer. As such, the “powerful” abstraction layer is designed to account for all of the different features and desired functionalities implemented by utilizing that layer. While in theory, this provides some cross-platform features for arbitrary types of software, in reality, low-level features that require full integration with a device's operating system are ignored, since this type of abstraction layer design tends to isolate platform-specific and platform-independent components. Further, building such an all-inclusive abstraction layer requires a large body of software code, which can be difficult to manage when maintaining platform abstraction layers for different platforms. What is therefore needed is a way to develop and build a cross-platform system that provides both high and low-level mobile device integration without taxing mobile device resources. What is further needed is a cross-platform system that may be implemented on any mobile communications device, regardless of manufacturer or service provider. What is also needed is a more lightweight abstraction layer that does not compromise power or functionality.
Because of the design of previous cross-platform systems and methods, the testing or quality assurance (“QA”) of these systems is tedious and difficult. Each platform-specific component must be tested. Changes to the code for the different components require writing new testing code to evaluate these new changes. What is therefore needed is a more efficient way to test the cross-platform system.
Currently, there are multiple mobile device operating systems that each cannot run software built for other operating systems. As such, developers must build software specifically for a mobile device operating system, and therefore the mobile software market is said to be “fragmented.” Recently, there has been some effort to create common operating system environments for emerging mobile communications devices. For example, Google® and the Mobile Handset Alliance, have developed a mobile communications device platform and operating system called Android™. Other common operating systems such as Windows Mobile®, Apple iPhone™, Research in Motion's Blackberry®, and Symbian® also exist. While using a common operating system is an effective solution to reduce fragmentation, it is unlikely to eliminate the problem. As long as there are multiple platforms that have significant market-share, software applications will need to run on the multiple platforms in order to achieve market penetration.
Some developers endorse virtualization as a possible solution. For example, Java® ME has been proposed as a viable cross-platform for mobile communications devices. However, it is well-known that running a virtual machine on a mobile communications device will typically tax its resources to the point of significant performance degradation. Further, virtual machine architecture is designed to be generic and therefore offers little to no access to the particular device running the virtual machine software. As such, running a virtual machine on a mobile communications device is not a desirable solution for highly-integrated software, such as security software, drivers and other software that significantly interfaces with the device's operating system.
Another cross-platform solution for mobile communications devices is the adoption of a common binary runtime environment, such as Qualcomm's BREW®. However, BREW is proprietary and limited to devices built upon or approved by Qualcomm®. As such, there are significant limitations as to the type, scope and breadth of applications allowable on BREW. Additionally, developers are restricted from accessing the low-level (operating system) features of the mobile communications device, which limits the amount of customization and integration available.
While these early efforts provide some cross-platform functionality, they are not adequate for highly-integrated software. What is therefore needed is a more efficient way for creating, developing and testing a cross-platform system for mobile communications devices that is easy to manage, implement and update.
There are many ways for protecting computing assets from the harmful effects of viruses, malware, adware, exploits, and other computer contaminants (also known collectively as “attacks”). Desktop, laptop and server computers enjoy numerous antivirus, network, and similar security software products that are able to detect security threats such as exploits, viruses, and malware. The detection of known viruses and malware often involves identifying the software code signatures or definitions of known viruses and malware, storing these signatures or definitions in a database on the computer, and comparing data with these signatures or definitions in order to determine whether or not the data contains a virus or malware. Detecting previously unknown viruses and malware may often involves analyzing data for certain characteristics or emulating the execution of data to determine what it would do if allowed to run on the host system. Identifying new attacks is a matter of updating a virus definition or virus signature database on the computer or modifying the rules associated with an unknown virus/malware detection system. This is feasible since computers have the hardware, software and memory resources to store and manage vast virus signature databases, as well as the processing resources to perform complicated analyses and emulate an execution environment. The detection of exploits or other attacks that can compromise a computer via a network often involves identifying the signatures of known exploits or attack, storing a database of signatures on the computer being protected, and comparing network data to these signatures in order to determine if the data contains a security threat. Like virus and malware signatures, network attack signatures can be updated in order to detect new security threats. As mentioned previously, such a system is made possible because computers have the computational and storage resources available to manage large attack signature databases and compare network data to many signatures before approving it.
Mobile communications devices lack the same power as computers, though they are often designed to provide some of the same functionalities as computers in a portable form. In order to provide these functionalities, mobile communications devices often retain a mobile or portable version of a desktop computer operating system or system architecture, such as Windows Mobile®, Apple OS X iPhone™ or Java® ME. As a result, some attacks directed to a traditional computer can easily translate or be modified to harm a mobile communications device. Additionally, the number and types of attacks specifically directed to the mobile communications device platform is growing.
Detecting attacks on a mobile communications device presents challenges not found on traditional computing platforms. As previously mentioned, mobile communications devices lack the hardware, software and memory resources of a traditional computer. As such, storing vast signature databases on the mobile communications device is not feasible, and running complicated analysis systems strains the device's memory, battery, and CPU. Other security solutions have been found unsuccessful at detecting attacks specifically directed to a mobile communications device, since mobile communications devices provide functionalities not found on traditional computers. For example, a mobile communications device may be attacked via network data, files, or executables received over various network interfaces such as Bluetooth, Wi-Fi, infrared, or cellular networks.
The lack of robust antivirus and attack preventative measures on mobile communications devices has serious security implications. Mobile devices are part of a critical infrastructure: as people depend on such devices to communicate, transmit and receive data, and access Internet and intranet websites, it becomes more important that these devices remain secure. If not protected, a significant portion of mobile devices may be vulnerable to criminal or cyber-terrorist attacks that could disrupt the normal functioning of both commerce and government. One skilled in the art could easily disrupt vital communications, use mobile communications devices to hack into supposedly secure servers storing confidential information, steal money via mobile payment mechanisms, or perform a host of other malicious and nefarious acts.
What is therefore needed is a way to prevent attacks and protect mobile communications devices without sacrificing device performance.
Mobile communications devices such as cell phones, smartphones, and PDAs, have advanced well beyond devices that simply carry voice communications. Today's mobile communications devices are frequently used to receive and transmit data as well, including files, email and SMS or text messages. This data may be received through one or more device “entry points,” such as over the cellular network, a data network, Wi-Fi, Bluetooth or others. These device entry points are also known as “network interfaces” because they each provide an interface to a different network. As people rely upon their mobile communications devices to transmit and receive data through these network interfaces, it becomes important to ensure that these network interfaces are secure. Each new network interface corresponds to a different communications protocol, allowing hackers and cyber-terrorists additional ways to discover and exploit vulnerabilities in the different protocols and/or network interfaces.
Since many mobile communications devices are designed to mimic the functionality of traditional desktop and laptop computing platforms, the methods used to protect these traditional platforms are often appropriated for the mobile communications device. However, traditional desktop, laptop and even server computers do not share the same network interface issues found in modern mobile communications devices. This is because traditional platforms typically use a single network interface, such as an Ethernet interface. This network interface typically uses a limited number of communications protocols, such as TCP/IP or other IP-based protocols. As such, protecting that network interface is simply a matter of monitoring the data received by that interface. In other words, unlike a mobile communications device that may have multiple network interfaces, a computer may only be secured at a single network interface.
For those computers that have multiple network interfaces, such as Bluetooth or infrared in addition to Ethernet, present security methods still monitor transmitted and received data, but the data is funneled to single software component tied to the computer's operating system. This component will typically apply what is well-known as the “least common denominator” method to determine if the received data presents any risks or inconsistencies. In essence, however, these prior security methods treat all incoming data as if they are received at the Ethernet interface. More specifically, these prior art security methods treat all data as if they are transmitted using an IP-based communications protocol. Some mobile communications devices mimic this type of security system by monitoring TCP/IP traffic received by the mobile communications device. However, this type of security system ignores the mobile communications device's ability to receive non-TCP/IP traffic. This is illustrated in FIG. 31.
FIG. 31 shows various hardware-implemented network, communications or software-defined interfaces such as infrared transceiver 3101, Bluetooth radio 3102, Wi-Fi radio 3103, USB interface 3104, cellular radio receiver 3105 including cellular data connection 3106 and SMS 3107, and near field communication 3108. In addition, various software-implemented interfaces, services and communications protocols are shown, including infrared services 3111, Bluetooth services including SDP 3112, OBEX 3113, HFP/HSP 3114 and BNEP 3115, other network services and applications 3116, WAP 3122 and WAP services 3117, SIM toolkit 3118, text messaging 3119 and other SMS services 3120. Data received utilizing these network interfaces, services and protocols generally travels directly to the operating system subsystem that handles, manages or executes this data. For example, data received by the infrared receiver 3101 or data in the form of an infrared communications protocol 3131 is managed by the operating system's infrared subsystem 3131. Data received by the Wi-Fi radio 3103, USB interface 3104, Cellular data connection 3106, or BNEP 3115 is managed by the operating system's networking subsystem 3133, where it may be further directed through TCP/IP subsystem 3121 to network services and applications 3116. FIG. 31 illustrates that various communications pathways a mobile communications device may utilize a variety of network interfaces and communications protocols. However, in prior art mobile communications device security systems, only TCP/IP or other traditional network traffic is monitored and analyzed. In other words, prior art security systems only protect received data traveling through Operating system's networking subsystem TCP/IP subsystem 3121 and/or the mobile communications device operating system network subsystem 3133. FIG. 31 illustrates that not all data will be transmitted to a mobile communications device using these communications pathways and, as a result, there are a number of vulnerabilities that are ignored by prior art security methods.
FIG. 31 also illustrates that certain communications protocols may be layered. For example, the Bluetooth radio 3103 may receive data encoded using the Bluetooth communications protocol stack. As such, the data may be further layered using SDP 3112, OBEX 3113, HFP/HSP 3114, BNEP 3115, etc. Not only are prior art systems unable to monitor data received over the non-TCP/IP portions of the Bluetooth network interface, but prior art security systems lack the ability to identify, examine and track lower-level protocol layers for any security threats.
What is therefore needed is a way to monitor all of the different network interfaces and that also tracks all of the protocols used by these network interfaces on a mobile communications device.
Prior art security systems also tend to focus on data as it is received or is stored on the mobile communications device. This does not provide a complete picture of all of the data communications to and from a mobile communications device, and in particular, does not prevent attacks that do not come over TCP/IP and do not utilize the file system before compromising the device. For example, if a mobile communications device receives self-propagating malware such as a worm which uses an exploit to propagate, prior art security systems may not detect the exploit being used to install the malware. After the exploit compromises the system, it can disable any security functionality and be able to install the worm to the file system without hindrance. Further, prior art security systems will not likely prevent the worm from spreading because outbound data transmissions, especially over non TCP/IP networks, are not often monitored. As such, present mobile communications devices are vulnerable to a multitude of attacks, which could not only disrupt daily life, government, and commerce, but also provides a significant vehicle for large-scale cyber-terrorist or criminal attacks.
What is therefore needed is a way to monitor outbound data transmission from a mobile communications device and prevent attacks that compromise the system before passing through the operating system's networking subsystem.
Today's mobile communications devices, such as cellular telephones, smartphones, wireless-enabled personal data assistants, tablet PCs, netbooks, and the like, are becoming more common as platforms for various software applications. A mobile communications device user now has more freedom to choose and install different software applications, thereby customizing the mobile communications device experience. However, while there are many positive software applications available on the market, the ability to interact, install, and operate third party software inevitably leaves the mobile communications device susceptible to vulnerabilities, malware, and other harmful software applications. Unlike desktop computers and other less portable computing devices that can install and run antivirus software to protect against harmful software applications, mobile communications devices lack the processing power or resources for effectively running analogous software.
Third party applications have been developed that provide rudimentary scanning functions on a mobile communications device; however, these applications are often device, operating system, or application-specific. As such, a single universal platform-agnostic system for efficiently monitoring, scanning, remedying, and protecting mobile communications devices does not exist. It would be desirable to provide such a system that works on any mobile communications device, that is hardware and software agnostic, and that can be continuously updated to provide constant real-time protection. Moreover, it would be desirable to provide an adaptable system that can act and react to the demands and changes affecting a number of mobile communications devices, thereby providing intelligent malware protection.
One feature common to many mobile communications devices is the fact that they are constantly connected to a network. However, despite this common link, it is difficult to safeguard mobile communications devices fully at the mobile network level, as devices may connect to additional networks and utilize encrypted services, both of which often bypass network level protection. Rather than rely only on the processing and memory resources of each mobile communications device on the network, it would be desirable to provide a system that protects mobile communications devices remotely, providing malware prevention and analysis measures to multiple devices without the overhead of those measures running locally on each device.
One of the issues that make it difficult to protect mobile communications devices from undesirable applications is the many different types of data and applications that are available for such devices. While service providers are able to manage the network traffic in providing applications, there is no current way to effectively monitor the behavior of these applications after they have been installed on a user's mobile communications device. As a further result, it is difficult to identify new, previously unknown malicious applications by their behavior and to track and prevent the spread or dissemination of damaging applications and data once they have been released to the network. It would be desirable to provide a system that can actively monitor a group of mobile communications devices in order gather data about the installation and behavior of applications on mobile communications devices.
Once such a system is in place, it would be desirable to use data and information gained about mobile communications device applications to help users make more educated decisions about the applications they choose to run on their mobile communications devices and to allow administrators and network operators to take preventative measures to further secure both individual devices and the network as a whole. It would be further desirable to develop a way to anonymously collect data about mobile communications device behaviors and activities in order to promote the development of safer mobile applications.
Mobile app stores are experiencing astronomical growth. Analysts estimate that the total global mobile applications market is expected to be worth upwards of $25 billion in the next several years. Factors contributing to the growth include advancements in network technologies, the lowering of mobile data usage cost, and the growing adoption of smartphones. Application marketplaces such as the Android Market and Apple Apps Store have provided a new business model for developers, brands, device manufactures, advertisers, and many others.
With so many different applications coming to the market, it is becoming very difficult for marketplace owners to categorize the applications, identify which applications they would like to distribute, identify which applications they would like to not distribute, and generally, keep abreast of changes. While there are a great number of good applications, there is also a great number of bad or undesirable applications. It can be difficult to tell which is which.
Therefore, there is a need for systems and techniques to provide timely and up-to-date information on mobile application programs.
Today's portable electronic devices, such as cellular telephones, smartphones, wireless-enabled personal data assistants, tablet PCs, netbooks, and the like, are becoming more common as platforms for various software applications. There are literally hundreds of thousands of mobile applications covering categories such as games, entertainment, music, movies, business, news, productivity, and many more. These applications are made available to consumers through online marketplaces such as the Android Marketplace, Apple AppStore, Amazon AppStore, and many others. An application may be offered for free or require payment. Developers may be compensated through commissions, the placement of advertisements in the applications, or both.
However, while there are many positive software applications available on the market, the ability to interact, install, and operate third party software inevitably leaves the device susceptible to vulnerabilities, malware, and other harmful software applications. Unlike desktop computers and other less portable computing devices that can install and run antivirus software to protect against harmful software applications, portable electronic devices lack the processing power or resources for effectively running analogous software.
There exist many unscrupulous people who engage in software piracy and hacking. Many of the application marketplaces are flooded with unauthorized application copies or versions. Everybody suffers. The developer fails to receive compensation and may not have the resources to continue research and development on other products. The unauthorized version of the application may have been modified with a virus or other malware code. Thus, the consumer suffers.
Therefore, there is a need for improved techniques and systems for computer security, including mobile application security.
There is a strong desire for administrators (e.g., chief information security officers (CISOs) or network administrators) to have a way to actually measure the degree their system is at risk. That is, administrators desire a quantified measure of risk in their system. And such administrators desire not just the facile quantities, e.g., a percentage of devices on which a protection mechanism was deployed, but rather a way to capture the amount of risk in a system. Such a captured or quantified amount of risk might be considered an “absolute” risk score for a system. In addition to such a quantified amount, an administrator would find it valuable to know how the risk level of their system compares to the risk levels of peer systems—their risk level compared to other systems in the same industry. That is, an administrator may wish to know their risk level compared to that or their peers. Furthermore, the definition of “peer” to any particular administrator may be fluid or difficult. And the administrator may wish to remain anonymous or may not wish to divulge who they consider to be peers. As a result, the administrator may prefer to select a customized peer group rather than subscribe to a standard definition of a peer group or subscribe to another administrator's definition of a peer group. For example, a small bank may consider itself to be more similar to retailers than to large banks. And for that reason, a small bank administrator might elect to know how the amount of risk in their system compares to retailers, rather than how the amount of risk compares to large banks.
What is therefore needed is a system and method for providing administrators with risk information regarding other networks so that an administrator may evaluate their system's level of risk in the context of their industry or other chosen peer group. What is also needed is a system and method for sharing risk information between administrators so that the collective group may address a risk. What is also needed is a system and method for sharing risk response between administrators of networks so that one network may benefit from a response to a risk or risk event where the response originated from or was implemented on a different network.
The source of an access request may be difficult to determine. For example, an enterprise employee visiting London, England on vacation with a sudden, urgent business issue may use free Wi-Fi in a coffee shop to VPN from her iPhone into her enterprise computer, which she left up and running in California. The employee may use that VPN access to command the enterprise computer to access enterprise resources. Typically, the enterprise backend would not know that the enterprise computer is projecting its display and sending enterprise data all the way to London. The enterprise would also not know the security status of the Wi-Fi connection or the iPhone.
What is therefore needed is a method for determining whether to allow or deny an access request based on knowledge of the source of the access request and knowledge of the security of the computing devices and network infrastructure involved in the transmission of the access request.
Applications of MPTCP involve tying together multiple network interfaces to communicate with, for example, a single application. MPTCP presents some problems for security analysis and protection because security solutions that rely on observing or intercepting communications will fail when the security solution only gets to observe or intercept some of the packets involved in a communication. An enterprise may have security policies in place relating to communication security that a user would prefer did not apply to the user's personal business or activities. However, an enterprise may have to address devices (e.g., bring-your-own-devices (BYODs)) that are used for personal business or activities, and enterprise related activities, and potentially both simultaneously.
What is therefore needed is a way to control or monitor the multiple protocols of MPTCP for enterprise related activities, but not for personal activities.